I/O Automaton Models and Proofs for 
Shared-Key Communication Systems 


Nancy Lynch 
MIT Laboratory for Computer Science 
545 Technology Square 
Cambridge, MA 02139, USA 
lynch@lcs.mit.edu 


August 9, 1999 


Abstract 


The combination of two security protocols, a simple shared-key communication pro- 
tocol and the Diffie-Hellman key distribution protocol, is modeled formally and proved 
correct. The modeling is based on the I/O automaton model for distributed algorithms, 
and the proofs are based on invariant assertions, simulation relations, and compositional 
reasoning. Arguments about the cryptosystems are handled separately from arguments 
about the protocols. 


1 Introduction 


Security protocols must satisfy important correctness requirements, which means that it is 
important to be able to think about them clearly and precisely. But they can also be large 
and complicated, which makes such reasoning difficult. Ways of decomposing the reasoning 
task into clearly separable pieces are needed. This includes separating different types of 
concerns, for example, distributed algorithms issues, cryptosystem computability issues, 
probabilistic issues, and issues of accurate modeling of reality. It also includes decomposing 
the protocols using the normal techniques for decomposing distributed algorithms, based 
on levels of abstraction and parallel composition of interacting components. 

This paper describes an experiment in modeling and analyzing security protocols, using 
I/O automata [26, 23] and the usual techniques that go along with them—a combination 
of invariant assertions, simulation relations, and compositional reasoning using traces. The 
aim of the experiment is to explore how these methods can help in decomposing the task 
of reasoning about security protocols. This model and these methods have been used 
successfully for decomposing the reasoning about many standard distributed algorithms 
(see, e.g., [23, 32, 25]), and about several distributed system designs (see, e.g., [13, 14, 17, 
20]), so it is worth discovering what they can do for security protocols. 

The experiment involves combining simple shared-key communication and key distri- 
bution protocols to implement private communication. In the case we describe in detail 
here, simple Diffie-Hellman key distribution [10] is used, the protocols tolerate only passive 
eavesdroppers, and only safety properties are considered. In another case in progress, dis- 
cussed briefly here, the more complex Diffie-van Oorschot-Weiner key distribution protocol 
[11], which tolerates adversaries that can intrude more actively, is studied. Later work will 
include liveness guarantees, formulated in terms of timing properties. 

Our main guideline in studying these protocols is to try to decompose the reasoning as 
much as possible, identifying sub-problems that can be treated separately. (Although the 
examples in this paper are simple enough to be understood informally, understanding how to 
decompose them is a good first step toward understanding how to decompose more complex 
examples.) The handling of each piece should be appropriately abstract. For example, in 
discussing protocol issues, cryptosystem computability issues should be summarized by 
assumptions saying that certain values are not “easily computable” from others; number- 
theoretic arguments about why these values are not (likely to be) easily computable should 
be treated at a lower level, as mechanisms to achieve the more abstract non-computability 
guarantees. Probabilistic issues should be treated separately, as far as possible. After 
dividing up the problems in this way, we expect that the main benefit of the I/O automaton- 
based methods will be in clarifying the distributed algorithm issues. Cryptosystem issues, 
for example, may be better treated by other means, for example, the inductive techniques 
of Paulson [30] or the strand space techniques of Fabrega, et al. []. However, a general 
framework should provide a rigorous way of combining the different types of issues. 

Similarly, we try to decompose the distributed algorithms themselves as much as possi- 
ble, by: 


1. Treating sub-protocols separately, then combining them using general theorems about 
automaton composition. 


2. Giving very high level automaton specifications for services, giving separate, detailed 
descriptions of implementing algorithms, and showing, by means of simulation rela- 
tions, that the algorithms implement the services. 


3. First studying a protocol using a natural, simple cryptosystem, and later trying to 
show that its correctness properties extend to modified versions that use more elabo- 
rate cryptosystems. 


4. Combining adversaries that interact with separate protocols into a single “colluding” 
unit. 


Because I/O automata are composed by means of shared actions, and because we are 
considering only safety properties in this paper, it is natural to describe external behavior of 
automata in terms of sets of traces (i-e., sequences of external actions). The simple trace se- 
mantics yields simple and powerful projection and pasting theorems (see, e.g., [23], p. 211), 
for the behavior of compositions of automata. However, in order to enable compositional 
reasoning about particular kinds of properties, the traces must contain all the information 
relevant for those properties. For example, in treating fault-tolerance properties such as 
wait-free termination and f-failure termination compositionally, in terms of traces, it is 
convenient to include in traces special fail input actions that signal the occurrence of fail- 
ure events (see, e.g., [23, 25]). Sometimes it is convenient to consider different strengths of 
failure actions (e.g., the good, bad, and ugly failure actions in [14]). Also, in order to treat 
timing properties compositionally, it is useful to include timing information into traces. 

In the case of security protocols, some important properties involve lack of knowledge. 
To treat this compositionally, one should include something about knowledge in the traces. 
Our approach here is to give explicit learn input actions and reveal output actions by which 
a component can learn new information and reveal its knowledge, and to constrain the 
component’s behavior in terms of these actions. 


Specifically, the paper contains the following. Section 2 presents a model for cryptosys- 
tems, which describe the data types encountered in the protocols, including messages, keys, 
and lower-level data from which keys are constructed. This data model also describes the 
functions that manipulate data, and the reachability (computability) relationships that say 
which values can be computed easily from which others. The data model is similar to others 
in the literature. Section 3 contains a brief review of the I/O automaton model. Section 4 
describes some “standard” types of automata that model certain components appearing in 
many systems: service environments, insecure channels, and eavesdroppers. 

Section 5 gives I/O automaton specifications for the two main security services con- 
sidered in this paper—private communication and key distribution. The specification for 
private communication is abstract: it talks only about communication and revealed informa- 
tion, and not, for example, about keys. Section 6 models and analyzes the implementation 
of private communication using an abstract key distribution service, and Section 7 treats 
the Diffie-Hellman implementation of key distribution. These protocols use particular cryp- 
tosystems, and the protocol proofs assume the limitations on easy computability expressed 
by those cryptosystems. The proofs are based on invariant assertions, and on simulation 
relations relating the protocols to the specifications for the services they are intended to 
implement. 


Section 8 shows what is involved in moving from a description of each of the two in- 
dividual protocols in terms of its own natural cryptosystem to a description in terms of a 
common, richer cryptosystem. For example, the shared-key protocol is initially analyzed 
in terms of abstract, unstructured keys taken from a simple “shared-key cryptosystem”. 
However, when one combines this protocol with Diffie-Hellman, it is necessary to consider 
a version that uses structured keys, taken from a richer “structured-key cryptosystem” . 

Section 9 puts the pieces together, to get an implementation of private communication 
that uses shared-key communication together with Diffie-Hellman key distribution. Most 
of this is accomplished automatically from the general projection and pasting theorems for 
I/O automata. Special arguments must be made for combining the insecure channels used 
in the two protocols, and for combining the two adversaries into one. Section 10 gives a 
final discussion. 


Related work: 

The I/O automaton model is similar to the labeled transition system models underlying 
process algebras. However, notation and proof techniques typically used for I/O automata 
differ greatly from the usual process algebraic notations and methods; notably, work based 
on I/O automata uses explicit, structured representations of automaton states. 

Many researchers have stated and proved invariant assertions for security protocols (see, 
for example, [19, 36, 33, 30]). On the other hand, simulation relations have not been used 
much in prior work on reasoning about security protocols. An example of work using 
simulation relation ideas is the work on “safe simplifying transformations” by Hui and 
Lowe [18]. Also, Abadi and co-workers have used simulation relation notions in proving 
equivalences for components of secure systems (see, e.g., [1, 3]). 

Our strategy of including in traces explicit information about what can be learned and 
what can be revealed is a key to our approach to compositional reasoning about security pro- 
tocols. Including this information makes simple traces rich enough to express at least some 
interesting security properties. A similar strategy, called “negative constraints”, is used by 
Cavalca and Segala in analyzing authentication protocols [8, 9]. This strategy differs from 
the “zero-knowledge” approach to proving secrecy properties (e.g., [16]) by specifying the 
particular information that can be learned and revealed, rather than assuming that noth- 
ing is learned or revealed. This extra flexibility makes it easier to compose specifications. 
Another difference between our work and work on zero-knowledge is that zero-knowledge 
proofs include probabilistic considerations, which we have so far avoided. 

Bellare and Rogaway have developed a framework for composing security protocols [6, 7]. 
Their approach is less formal than ours, but it takes probabilities into account. Lincoln, 
Mitchell, Mitchell, and Scedrov [21] present a formal approach to studying the interactions 
between protocols and cryptographic primitives, again taking probabilities into account. 
This work can be regarded as a more formal version of the work of Bellare and Rogaway. 
It is based on a form of z-calculus [29] and probabilistic polynomial time process models. 

Our work differs from work on formal logics for security for example, the BAN logic 
of Burrows, Abadi, and Needham [2], in that ours is carried out entirely at the level of 
automaton semantics. However, our work is compatible with work on security logics, in 
that it should be possible to express our proof methods using formal logics. Also, it should 
be possible to interpret some security logics in terms of I/O automata; the effort would be 


similar to Abadi and Tuttle’s construction of an automaton semantics for a derivative of 
the BAN logic [4]. 

Our work makes extensive use of inductive proofs, mainly for verifying invariants and 
simulation relations. Paulson [30] has developed an extensive collection of methods for rea- 
soning inductively about cryptographic protocols, all supported by the Isabelle interactive 
theorem prover [31]. His approach includes some methods for proving secrecy properties, 
which involve showing that certain values are not reachable from other values within cryp- 
tosystems. We think that such methods may be useful for constructing formal proofs of 
cryptosystem unreachability results like the ones needed in this paper. Other approaches 
that should be useful in proving cryptosystem reachability results include the rank function 
approach of Schneider [33] and the strand space techniques of Fabrega et al. 

All of the related work mentioned above adopts a model where the adversary may be 
active, not just an eavesdropper. We believe that this is not a fundamental difference, in 
that our general approach can be extended to model more active adversaries. 

Sheyner and Wing [34] have formalized much of the approach of this paper using con- 
servative extensions to theories supplied with the theorem prover Isabelle. In particular, 
they have formalized shared-key cryptosystems, private communication, and essentially all 
the automata appearing in Section 6 of this paper. They have carried out interactive proofs 
using Isabelle for the fact that 5; simulates PC, for the invariants in Section 6.3, and for 
several other invariants useful in the simulation argument. They are continuing to model 
other security protocols using the same approach. 

An earlier version of the present paper appeared in the 12th IKEE Computer Security 
Foundations Workshop [24].! 


2 Data Model 


This section presents a basic model for the data types used in the protocols. 


2.1 Cryptosystems 


We use to denote the empty string. 
A cryptosystem signature S consists of: 


e TNs, a set of type names. 

e FNsg, a set of function names. 

e domains, a mapping from FN g to (TN s)*. 
e ranges, a mapping from F'Ns to TNs. 

e ENs C FNs, a set of easy function names. 


A constant name is a function name f such that domains(f) = ». Let CNs C FN g denote 
the set of constant names of C. We omit the subscript S where no confusion seems likely. 
A cryptosystem C consists of: 


‘Unfortunately, subsection numbers are messed up in that version. A corrected copy of that paper appears 
at URL http://theory.1cs.mit.edu/tds/papers/Lynch/CSFW. html. 


e A cryptosystem signature sigc. We write TNc as shorthand for TN sig,, etc. 
e setc, a mapping from TN¢ to disjoint sets. 


e func, a mapping from FN¢ to functions; We require that if domaine (f) = (ti,...,tk) 
and rangec(f) =¢t then func(f) : sete(ti) x +++ x sete(t,) > setc(t). 


We write sete for Ure ry, setc(t). We omit the subscript C where no confusion seems likely. 
If X U{y} C sete, we say that y is easily reachable from X in C provided that y is obtainable 
starting from elements of X, by applying only functions denoted by function names in ENe. 


2.2 Term Cryptosystems 


If S is a cryptosystem signature, then the terms of S, and their types, are defined recursively, 
as follows: 


1. Ifc € CNg and ranges(c) =t, then c is a term and types(c) =t. 


2. If f € FNgs, domains(f) = ti, te,...,th, where k > 1, ranges(f) = t, and e1,...,e% 
are terms of types t1,...,t,, respectively, then the expression e = f(e1,...,e¢) is a 
term, and types(e) =t. 


Let Termsgs(t) denote the set of terms of S of type t. Let Termsg denote the set of all 
terms of S. 

Some of the cryptosystems we consider are best understood as term algebras derived 
from cryptosystem signatures. In these cases, the values of the various types are, formally, 
equivalence classes of terms: An equivalence relation R on Termssg is said to be a congruence 
provided that the following hold. 


1. If eRe’ then types(e) = types(e’). 


2. Suppose that f € FN gs, domains(f) = ti,te,...,t,, where k > 1, ranges(f) = t, 
€1,---,€k are terms of types ¢1,...,¢,%, respectively, OL pi ey Ch are terms of types 
t1,...,tp, respectively, and for alli, 1 <i <k,e;Rej. Then f(e1,...,e,)Rf(e1,...,e%)- 


Let S be a cryptosystem signature and R a congruence on Termss. Then the term cryp- 
tosystem C for S and RF is the unique cryptosystem satisfying: 


e sige =S. 


e Ift € TNe, then setc(t) is the set of all R-equivalence classes of terms of type ¢ in 
Termsc. 


e If f € FNe, domaince(f) = (t1,...,t,) and rangec(f) =t then func(f) is the function 
from setc(t1) x --- x setc(t,) to setc(t) defined as follows. Suppose that e; € setc(t;) 
for alli, 1 <i <k. Then fune(f)([ei]r,---.[ex]z) is defined to be [f(e1,...,ex)]R- 
(Since R is a congruence, this is well-defined.) 


We use the notation Re for the congruence relation R of C. If e € Termse, then we write 
[e]c for the equivalence class of e with respect to Re. Also, if EF C Termse then we write 
[E|c for the set of equivalence classes [ele for e € E. 


2.3. Cryptosystem Examples 


In this subsection we give the specific kinds of cryptosystems used later in this paper. 
These are: shared-key cryptosystems, used in shared-key communication; base-exponent 
cryptosystems, used in Diffie-Hellman key distribution; and structured-key cryptosystems, 
which are essentially combination of shared-key and base-exponent cryptosystems, and are 
used when shared-key communication and Diffie-Hellman key distribution protocols are 
combined. 


2.3.1 Shared-key cryptosystems 


A shared-key cryptosystem C is a term cryptosystem. The signature S = sige is defined 
as follows. TN gs consists of two type names: “M” for messages and “Kk” for keys. FN gs 
consists of: 


e enc, with domain(enc) = (“M”,“K”) and range(enc) = “M”. 
e dec, with domain(dec) = (“M”,“K”) and range(dec) = “M”. 


e MConsts, a set of message constant names, with range(m) = “M” for all m € 
MConsts. 


e KConsts, a set of key constant names, with range(k) = “K” for all k € KConsts. 
EN gs = {enc, dec}. The relation R is defined by means of all equations of the form: 
e dec(enc(m,k),k) =m, where m,k € Termss, type(m) = “M”, type(k) = “kK”. 


Specifically, we define R to be the smallest congruence relation on Termss that groups 
together all terms that are related by the given equations. 

The following lemma gives some basic properties of a shared-key cryptosystem, used 
later in the proof of an invariant for a shared-key communication protocol (Lemma 6.3). 
Many properties of this sort are needed in this paper. However, we will not continue to be 
as explicit as we are here, but will revert to simply citing “properties of the cryptosystem”. 
A careful treatment of such properties is a separate effort, and would benefit from the use 
of other methods, as discussed in the Introduction. 


Lemma 2.1 Let C be a shared-key cryptosystem, S its signature and R its congruence 
relation. 


1. Suppose that e, and e2 are terms of type “M” with e, Rez. Let enc; and dec; denote 
the respective number of occurrences of enc and dec in e;, 1 € {1,2}. 
Then enc, — dec, = encg — deco. 


2. For all m1,m2 € MConsts, k € KConstgs: 
enc(m,,k) is not R-related to mo. 


Proof: Part 1 is proved by induction on the number of substitutions required to relate 
one term to the other. Since there is only one kind of substitution, and it preserves this 
difference, the result holds. Part 2 follows from Part 1. o 


2.3.2 Base-exponent cryptosystems 


A base-exponent cryptosystem C is a term cryptosystem in which, letting S = sige: TNs 
consists of two type names, “B” for bases and “X” for exponents, and FN s consists of: 


e exp, with domain(exp) = (“B”,“X”) and range(exp) = “B”. 
e BConsts, a set of base constant names, with range(b) = “B” for all b € BConsts. 


e XConst1s and XConst2 5, two disjoint sets of exponent constant names, with domain(x) = 
d and range(x) = “X” for all x € XConst1s U XConst2 gs. 


EN gs = {exp} U BConsts. The relation R is defined by means of all equations of the form: 


e exp(exp(b,x),y) = exp(exp(b, y), x), where b, x,y € Termss, type(b) = “B”, type(x) = 
type(y) = “X”. 


Define B25 to be the set of all terms of the form exp(exp(b,x),y), where b € BConsts, 
a € XConstls and y © XConst2s. An augmented base-exponent cryptosystem is a base- 
exponent cryptosystem together with a distinguished element b0s of BConstgs. 


2.3.3 Structured-key cryptosystems 


A structured-key cryptosystem is a combination of a shared-key cryptosystem and a base- 
exponent cryptosystem, where certain terms of the base-exponent cryptosystem are iden- 
tified with the keys. A structured-key cryptosystem C is a term cryptosystem in which, 
letting S = sige: TN sg consists of the type names “M”, “B”, and “X”, and FN gs consists 
of: 


e enc, with domain(enc) = (“M”,“B”) and range(enc) = “M”. 
e dec, with domain(dec) = (“M”,“B”) and range(dec) = “M”. 
e exp, with domain(exp) = (“B”,“X”) and range(exp) = “B”. 


e MConsts, a set of message constant names, with range(m) = “M” for all m € 
MConsts. 


e BConsts, a set of base constant names, with range(b) = “B” for all b € BConst. 


e XConst1s and XConst2s, two disjoint sets of exponent constant names, with range(x) = 
“X” for all e € XConstls U XConst2 gs. 


EN gs = {enc, dec, erp} U BConsts. The relation R is defined by means of all equations of 
the forms: 


e dec(enc(m,b),b) =m, where m,b € Termss, type(m) = “M”, type(b) = “B”. 
e exp(exp(b, x),y) = exp(exp(b,y), x), where b,z,y € Termss, type(b) = “B”, type(x) = 
type(y) = “X”. 


Once again, we write B2c¢ for the set of terms of the form exp(exp(b,x),y), where b € 
BConstc, x € XConst1c, and y © XConst2ce. An augmented structured-key cryptosystem 
is a structured-key cryptosystem together with a distinguished element b0s of BConsts. 


3 Input/Output Automata 


We use I/O automata as defined in [23]. Briefly, an I/O automaton A is a state machine 
having a signature consisting of a set of actions, classified as input, output, and internal 
actions. A also has a set of transitions, which are (state, action, state) triples. It is assumed 
that every input action is enabled in every state. Since we do not deal with liveness in this 
paper, the tasks defined in [23] are irrelevant. 

An execution fragment of A is an alternating (state, action, state,...) sequence, where 
successive triples correspond to transitions of A. An execution is an execution fragment 
that begins with a start state. The external behavior of A is modelled by the set of traces, 
which are the sequences of external actions arising from the executions. 

If A and B are I/O automata with the same external signature, then we say that A 
implements B provided that every trace of A is also a trace of B. Parallel composition 
of automata is defined by identifying external actions with the same name in different 
automata. We use notions of invariants and simulation relations in the usual ways; for 
definitions, see, for example [23]. 

In particular, a simulation relation from A to B is a relation F from states(A) to 
states(B) satisfying the following two properties: 


1. Each start state of A is F-related to some start state of B. 


2. For each step (54,7, s',) of A and each state sg of B with (s4,5,) € F, there is a 
“corresponding” execution fragment of B: it has the same trace as the given step, 
and spans from sg to some state s/,, where (s/,, 5‘,) € F. 


The key fact about a simulation relation is expressed by: 


Theorem 3.1 If there is a simulation relation from A to B then A implements B. 


4 Some Generally-Useful Automata 


In this section, we give automaton models for some system components that will be used 
frequently in modeling security protocols, namely, environments for security services, inse- 
cure channels, and eavesdroppers. They are presented in a parameterized fashion so that 
they can be used in different contexts. We model these components as automata (rather 
than, for example, by using trace properties) for uniformity with the way we will model 
algorithms and system specifications, and because this makes it possible to reason about 
them assertionally. 


4.1 Environment Automata 


In this subsection we assume that U is a universal set of data values, A is a nonempty 
finite set of adversary ports (that is, locations where information can be communicated 
to an adversary), and N C U. The environment automaton Enu(U,A,N) models any 
entities other than the channels from which an eavesdropper may learn information. The 
specification says that the environment is theoretically capable of communicating elements 
of U at any adversary port a € A, but in fact does not communicate any elements of N. 


Env(U,A,N) : 


Signature: 
Input: Output: 
None learn(uja,u€U,aEeA 
States: 


No variables 


Transitions: 


learn(u)a 
Precondition: 
wéN 
Effect: 
none 


4.2 Insecure Channel Automata 


In this subsection we assume that U is a universal set of data values, P is a nonempty 
finite set of client ports, and A is a nonempty finite set of adversary ports. The insecure 
channel admits send and receive actions for all elements of U. It also has eavesdrop output 
actions, by which information in transit passes to an outsider. The insecure channel allows 
any message in transit to be communicated to an outsider. 


IC (U, P, A): 
Signature: 
Input: Output: 
IC-send(u)p,q,u€U, p,ge P,p#4 IC-receive(u)pq, u€ U,p,qe P,p#q 
eavesdrop (t)p,q,a5 WE U, Pd € P, Pp # q, @ € A 
States: 


for every p,g€ P, pF: 
buffer(p,q), a multiset of U, initially empty 


Transitions: 
IC-send(u) p,q eavesdrop (t)p,q,a 
Effect: Precondition: 
add u to buffer (p,q) u € buffer (p,q) 
Effect: 
IC-receive(u) p,q none 
Precondition: 
u € buffer (p,q) 
Effect: 


remove one copy of u from buffer (p, q) 


4.3. Eavesdropper Automata 


In this subsection we assume that C is a cryptosystem, P is a nonempty finite set of client 
ports, and A is a nonempty finite set of adversary ports. We define a model for an eaves- 
dropper, as a nondeterministic automaton Eve(C, P, A). Eve simply remembers everything 
it learns and hears, and can reveal anything it has, at any time. It does this by maintaining 
a variable has, initially @. The value of has may change only in restricted ways: When 
eavesdrop (t)pq,a or learn(u)a occurs, u gets added to has. Also, when an internal compute 
action occurs, the value resulting from applying an easy function (one in ENc) to values 
in has may be added to has. We restrict the reveal(u) output so that u € has, that is, 
Eve can only report a value that it “has”. Similar treatments of known information appear 
elsewhere in the literature, for example, in [12, 19, 28, 27]. 


Eve(C, P, A): 
Signature: 
Input: Internal: 
eavesdrop(u)p,qa, UE sete, p,gEP,p#q,aEA compute(u, fia, f€ HNc, aE A 
learn(u)a, u€ sete, aE A 
Output: 


reveal(u)a, u€ setc, ac A 


States: 
has C setc, initially @ 


Transitions: 
eavesdrop (u) p,q,a reveal (U)a 
Effect: Precondition: 
has := has U {u} u € has 
Effect: 
learn(u)a none 
Effect: 
has := has U {u} compute(u, fa 
Precondition: 
{ui,..., ux} C s.has 
U= f(ur,..., uk) 
Effect: 


has := has U {u} 


5 The Services 


In this section, we describe the two services that are implemented by the protocols in this 
paper. They are described as automata, which is convenient for assertional reasoning. The 
use of input and output actions provides convenient ways of composing these automata with 
others, and of describing what is preserved by implementation relationships. For simplicity, 
we write these specifications to describe only safety properties, although the same methods 
can be used to handle liveness properties, formulated as time bounds (see, e.g., [22, 23]). 
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5.1 Private Communication 


This section contains a specification of the problem of achieving private communication 
among the members of a finite collection P of clients. The specification expresses three 
properties: (1) only messages that are sent are delivered, (2) messages are delivered at 
most once each, and (3) none of the messages is revealed at any “adversary port”. We 
describe the problem using a high-level I/O automaton specification PC (U, P, M, A), where 
U is a universal set of data values, P is a nonempty finite set of client ports, M C U is 
a set of messages, and A is a nonempty finite set of adversary ports. This specification 
makes no mention of distribution or keys; these aspects will appear in implementations 
of this specification, but not in the specification itself. The specification simply describes 
the desired properties, as an abstract machine. As usual for automaton specifications, the 
properties, listed separately above, are intermingled in one description. 


PC(U, P, M, A): 
Signature: 
Input: Output: 
PC-send(m)p,q, MEM, p,qgqe P, p#q PC-receive(u)pq, u€ U,p,qe P,p#q 
reveal(u)a, wEU, aE A 
States: 


for every pair p,q € P, p#q: 
buffer (p,q), a multiset of M 


Transitions: 
PC-send(m)p,q reveal(u)a 
Effect: Precondition: 
add m to buffer (p,q) u¢ M 
Effect: 
PC-receive(u)p,q none 
Precondition: 
u € buffer (p,q) 
Effect: 


remove one copy of u from buffer (p, q) 


Properties 1 and 2 above, which express at-most-once delivery of messages that were actually 
sent, are expressed by the transition definitions for PC-send and PC-receive. Property 8, 
secrecy, is expressed by the constraint for reveal. 


5.2 Key Distribution 


This is a drastically simplified key distribution service, which distributes a single key to 
several participants. We do not model requests for the keys, but assume that the service 
generates the key spontaneously. The service does not grant any other values, and does 
not reveal any key in K at any adversary port. The simplified key distribution service is 
specified by the automaton KD(U, P, K, A), where U is a universal set of data values, P is 
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a nonempty finite set of client ports, K C U is a set of keys, and A is a nonempty finite set 
of adversary ports. 


KD(U, P, K, A): 
Signature: 
Input: Internal: 
none choose-key 
Output: 


grant(u)p,u€U,pEeP 
reveal(u)a, ue U,aE A 


States: 


chosen-key, an element of K U {L}, initially L 
notified C P, initially 0 


Transitions: 
choose-key reveal (U)a 
Precondition: Precondition: 
chosen-key = L u¢ K 
Effect: Effect: 
chosen-key := choose k where k € k none 
grant(u)p 
Precondition: 


chosen-key # L 
u = chosen-key 


p ¢ notified 
Effect: 
notified := notified U {p} 


6 Implementing Private Communication using Shared Keys 


This section describes a straightforward shared-key communication protocol. The protocol 
simply uses a shared key, obtained from a key distribution service, to encode and decode 
messages. Throughout the section, we assume that C is a shared-key cryptosystem, P is a 
set (of clients) with at least 2 elements, and A is a nonempty finite set (of adversaries). 


6.1 The Encoder and Decoder 


We define parameterized encoder and decoder automata, parameterized by the shared-key 
cryptosystem C, the set P of clients, and elements p,q € P, p # q. The encoder encrypts 
messages from client p using the granted key, and sends the encrypted messages on the 
insecure channel from p to g. Note that, in the code for I[C-send(u), we are using the 
abbreviation enc for func(enc) — that is, we are suppressing mention of the particular 
cryptosystem C. 


Enc(C, P)pq, where p,qeEP, pq: 


Signature: 
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Input: Output: 
PC-send(m)p,qg, m € [MConstc] IC-send(u) p,q, u € sete 
grant(u)p, u € sete 


States: 


buffer, a multiset of elements of [MConstc], initially empty 
shared-key € [KConstc] U {L}, initially L 


Transitions: 
PC-send(m)>,q grant(u)p 
Effect: Effect: 
add m to buffer if w € [KConstc] then 


shared-key := u 
IC-send(u) p,q 
Precondition: 
m is in buffer 
shared-key # L 
u = enc(m, shared-key) 
Effect: 
remove one copy of m from buffer 


The decoder receives messages from the insecure channel from p to q, decrypts them, and 
delivers the decrypted messages to q. 


Dec(C, P)yq, where p,qgeEP,p#q: 


Signature: 
Input: Output: 
IC-receive(u)p,q, u € sete PC-receive(u)p.q, u € sete 


grant(u)g, u € sete 


States: 


buffer, a multiset of elements of setc(“M”), initially empty 
shared-key € [KConstc] U {L}, initially L 


Transitions: 
IC-receive(u) p,q grant(u)q 
Effect: Effect: 
if u € setc(“M”) then if wu € [KConstc] then 
add u to buffer shared-key := u 


PC-receive(u) p,q 
Precondition: 
m is in buffer 
shared-key # L 
u = dec(m, shared-key ) 
Effect: 
remove one copy of m from buffer 
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PC-receive 


PC-send , , 12 


IC-receive , , 


IC-send , 5 


eavesdrop 


Figure 1: 5); P = {1,2}, A= {3}; A’ = {4} 


6.2 The Complete Implementation 


In the rest Section 6, we assume that U = sete, M = [MConstc], K = [KConstc], N = 
MUK,U' isa set with K CU’, and A’ is a nonempty finite set, disjoint from A. 

The implementation consists of encoder and decoder components, an insecure chan- 
nel, eavesdropper, and environment, plus a key distribution service. More precisely, the 
implementation, S;(C, P, A,U’, A’), is constructed by composing the following automata: 


e Enc(C,P)pq, Dec(C, P)pg, PIE P, DAG. 
e IC(U,P, A), Eve(C, P, A), Env(U, A, N). 
e KD(U',P, K, A’), a key distribution service. 


and then hiding all the eavesdrop, IC-send, IC-receive, grant, and learn actions, and all the 
reveal, actions for a € A’. That is, we hide all but the external actions of PC(U, P, M, A), 
which are the PC-send and PC-receive actions, and the reveal, actions for a € A. We 
sometimes omit explicit mention of parameters of S, (and of other systems and components), 
when we think that confusion is unlikely. Figure 1 contains an interaction diagram for 5S}. 

Note that, in this system, the eavesdropper Eve does not acquire any information directly 
from the KD component. Later, in Section 9, we will combine this eavesdropper with 
another that arises in the key distribution service implementation. 

Our system model says that the eavesdropper learns no elements of N = MU K from 
outside sources. This choice of N is fine for this protocol, but we do not have a general 
prescription for how to choose useful sets N for all protocols. “Useful” here means that the 
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set should have a simple definition, should be large enough to include all values that the 
adversary could use to break the protocol, and should be small enough to exclude values 
produced by other protocols with which the given protocol is to be composed. The work of 
coming up with a good choice of N seems to be something of an art, similar to coming up 
with a useful invariant. 


6.3. Invariants 


In system $1, we use Ency 4, Decp gq, [C, Eve, and KD as “handles” to help in naming state 
variables in the composed state. This handle naming device for state variables is taken 
from [35]. The first invariant says that the keys granted by the key distribution service are 
consistent. 


Lemma 6.1 In all reachable states of S,, the following are true: 


1. If Encyq.shared-key # 1 then Encp q.shared-key = KD.chosen-key. 


2. If Decp q.shared-key # 1 then Decyq.shared-key = KD.chosen-key. 
Proof: By a simple induction on the length of an execution leading to a state. O 
The next invariant says that all elements that appear in the insecure channel are of type 
“M”. 
Lemma 6.2 In all reachable states of S,, the following are true: 

1. Ifu is in IC.buffer, , then u € setc(“M”). 


The next invariant says that no element of N (= M UK; recall that M = [MConst¢]) 
appears in the insecure channel. 


Lemma 6.3 In all reachable states of S,, the following are true: 
1. For allp,q€ P, p#4q, and allu€ N, u ¢ IC. buffer(p, q). 


Proof: By induction on the length of an execution. 

Base: The claim is true in the initial state, because the channel is initially empty. 
Inductive step: Consider a step (s, 7,8’) of the implementation, where s satisfies the invari- 
ant. The interesting case is: 


1. IC-send(u)p,q, where u = enc(m, k) 
The precondition and type considerations imply that m € [MConstc] and k € [KConst¢]. 


So mn MConste # ; let m’ be any element inmMMConstc. Similarly, kN KConstc # 
); let k’ be any element in kM KConstc. Then enc(m’,k’) € u. 


We claim that u ¢ [MConstc]. Suppose it is and let m” be any element in uN MConstc. 
Then [enc(m’, k')] = u = [m"”]. But Lemma 2.1 implies that enc(m’,k’') and m” are 
not equivalent terms. It follows that u ¢ [MConstc], which implies that this event 
does not add an element of M = [MConstc] to the channel IC. 


The fact that this event does not add an element of K = [KConstc] to the channel is 
easy to see, because the type of any element in any equivalence class in [KConstc] is 
“K”, the type of any element in enc(m,k) is “M”, and elements of one equivalence 
class all have the same type. 
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As a corollary to the previous invariant, we can show that no N elements appear in Eve.has. 
Lemma 6.4 In all reachable states of 5S, the following are true: 
1. IfwEe N then u ¢ Eve.has. 


Proof: By induction. 
Base: The claim is true in the initial state, because the Eve.has is initially empty. 
Inductive step: Consider a step (s, 7,5’) of the implementation, where s satisfies the invari- 
ant. The interesting cases are: 

1. m = eavesdrop(u)nq,a 


The fact that this preserves the claim follows from Lemma 6.3, applied to state s. 


2. m =learn(u)a, aE A 


The precondition (in Enu(U, A, N)) says that u ¢ N, so this cannot cause a violation. 


3. m= compute(u, f)a,aEA 
Since the claim is true in s, it must be that no element of N is in s.Eve.has. But this 
means that no equivalence class of type “K” is included in s.Eve.has (because the 
only such classes are the ones in |[KConstc]). But then 7 cannot be enabled, because 
both easy functions, enc and dec, depend on a key class being in has. 


6.4 Implementation Proof 


We show that S$; implements PC (U, P, M, A) using a simulation relation from 5S) to PC(U, P, M, A). 
The relation F’ is defined by saying that (s,t) € F’ provided that the following holds: 

For each p,q € P, p # q, t.buffer(p,q) is the multiset union of three multisets, Ai, Ao, A3, 

of U, where: 


1. Ay = s8.Encpq.buffer. 
2. Ao = dec(s.IC.buffer (p,q), s.KD.chosen-key) if s.KD.chosen-key # 1 else Q. 
3. Az = dec(s.Decyq.buffer, s.KD.chosen-key) if s.KD.chosen-key # 1 else 0). 


That is, each high-level multiset of messages in transit is obtained from the messages in the 
buffers at the encoder and decoder, plus those in transit in the low-level insecure channels. 
The messages in the insecure channels and in the decoder buffer must be decoded for the 
correspondence. 


Theorem 6.5 F is a simulation relation. 


Proof: We check the two conditions required in the definition of a simulation relation: 
Start condition: This is easy, because all the relevant multisets are empty. 

Step condition: Consider (s,7, s’) in the implementation, and (s,t) € F', where both s and 
t are reachable states. The interesting cases are: 
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1. m = IC-send(u)p,q, where u = enc(m, k) 


This maps to the trivial one-state execution fragment t of PC(U,P,M, A). We must 
argue that (s’,t) € F. This follows because this event removes m from Encpq.buffer 
as it adds the encoded version u to the insecure channel, and because of the equations 
relating enc and dec. Lemma 6.1 is also used here, to ensure that the keys used for 
encoding and decoding are the same. 


2. m = IC-receive(u) pq 
The key point is that u is accepted by Dec, because it is of type “M”. This following 
from Lemma 6.2. 

3. 7 = PC-receive(u) pq 


This corresponds to the same action in the specification automaton. In this step, 
u = dec(m, s.KD.chosen-key) for some m € s.Decp4.buffer (we use Lemma 6.1 here). 
Thus, by definition of the correspondence F’, u € t.buffer(p,q), which means that 7 
is enabled in the specification automaton, in state t. Let t’ be the unique resulting 
state. 


To show that (s’,t') € F, the key facts are that one copy of m is removed from 
8.DeCpq.buffer while a copy of u is removed from the abstract channel t.buffer(p, q). 
Since u = dec(m,s.KD.chosen-key), this preserves the correspondence between the 
multisets. 


4. r = reveal(u)a 


This corresponds to reveal(u)q in the specification. We must show that u ¢ M. The 
precondition for reveal(u), (in Eve) implies that u € s.Eve.has. Lemma 6.4 implies 
that u ¢ N, which implies that u ¢ M. 


Theorem 6.6 S)(C,P, A,U’, A’) implements PC(U, P, M, A). 


Proof: By Theorem 6.5 and Theorem 3.1. O 


(An expanded version of) the results of this section have been checked by Sheyner and Wing 
using the Isabelle theorem prover. 


7 Diffie-Hellman Key Distribution Protocol 


This section describes the Diffie-Hellman key distribution protocol. Throughout the section, 
we assume that C is an augmented base-exponent cryptosystem, P = {pl,p2}, and Aisa 
nonempty set. 
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7.1 The Endpoint Automata 


We define two symmetric automata, for the two elements of P. The automaton for pl 
chooses an exponent x from the set XConst1, raises the distinguished base element b0 to 
the power x, and sends the result to p2. When it receives a corresponding value from p2, it 
raises that value to the power x and grants the result to the client as a key. 


DH(C, P)pi: 
Signature: 
Input: Internal: 
IC-receive(b)p2,91, b € setc(“B”) choose-exp 1 
Output: 


IC-send(b)pi,p2, 6 € setc(“B”) 
grant(b)pi, b € setc(“B”) 


States: 


chosen-exp € [XConst1c] U {1}, initially 1 
base-sent, a Boolean, initially false 
reud-base € setc(“B”) U{L}, initially L 
granted, a Boolean, initially false 


Derived variables: 
chosen-base € setc(“B”) U{L}, given by: 
if chosen-erp # | then exp([b0c], chosen-exp) else L 


Transitions: 
choose-exp 1 IC-receive(b) p2,p1 
Precondition: Effect: 
chosen-exp = L rcud-base := b 
Effect: 
chosen-exp := choose © grant(b) p1 
where x € [XConst1c] Precondition: 
chosen-exp # L 
IC-send(b) p1,p2 revd-base # L 
Precondition: b = exp(rcvd-base, chosen-exp ) 
chosen-exp # L granted = false 
b = chosen-base Effect: 
base-sent = false granted := true 
Effect: 


base-sent := true 


The automaton for p2 is the same, but interchanges uses of pl and p2, and uses XConst2 
instead of XConst1. 


DH(C, P) po: 


Signature: 
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Input: Internal: 
IC-receive(b) pi,p2, b € setc(“B”) choose-exp yo 
Output: 
IC-send(b)p2,p1, 6 € setc(“B”) 
grant(b)p2, b € setc(“B”) 


States: 
chosen-exp € [XConst2c]U {1}, initially L 
base-sent, a Boolean, initially false 
revd-base € setc(“B”) U{L}, initially L 
granted, a Boolean, initially false 


Derived variables: 
chosen-base € setc(“B”) U{L}, given by: 
if chosen-erp # | then exp([b0c], chosen-exp) else L 


Transitions: 
choose-exp yo IC-receive(b) p1,p2 
Precondition: Effect: 
chosen-exp = 1 revd-base := b 
Effect: 
chosen-exp := choose x grant (b) p2 
where x € [XConst2c] Precondition: 
chosen-exp # L 
IC-send(b) p2,p1 rcevd-base # 1 
Precondition: b = exp(rcvd-base, chosen-exp ) 
chosen-exp # L granted = false 
b = chosen-base Effect: 
base-sent = false granted := true 
Effect: 


base-sent := true 


7.2 The Complete Implementation 


In the rest of Section 7, we assume that U = setc, K = [B2c] (the set of doubly- 
exponentiated bases), X = [XConst1¢] U[XConst2c], and N= KUX. 

The implementation consists of two endpoint automata, an insecure channel, an eaves- 
dropper and an environment. Specifically, implementation Sj(C,P,A) is constructed by 
composing the following automata: 


e DH(C,P),, p € P, endpoint automata. 
e IC(U, P, A), Eve(C, P, A), Env(U, A, N). 


and then hiding all the eavesdrop, IC-send, IC-receive, and learn actions. That is, we 
hide all but the external actions of KD(U, P, K, A), which are the grant and reveal actions. 
Figure 2 contains an interaction diagram for S9. 
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Figure 2: S2; P ={1,2}; A ={4} 


7.3. Invariants 


In system $2, we use DH(p) for p € P, IC, and Eve as handles to help in naming state 
variables in the composed state. The first invariant says that messages that have been 
received or are in transit are correct. 


Lemma 7.1 Jn all reachable states of Sg, the following are true: 


1. If DH(p).rcvd-base #4 L and q # p then DH(q).chosen-erp # 1, and DH (q).rcud-base = 
DH (p).chosen-base. 


2. Ifu € IC.buffer(p, q), then DH (p).chosen-erp # 1, and u = DH (p).chosen-base. 


The next invariant says that no N elements ever appear in Eve.has or in the insecure 
channel. 


Lemma 7.2 In all reachable states of So, the following are true: 
1. For allp,qeE P, p#4q, andallu € N, u ¢ IC.buffer(p, ¢q). 
2. IfuEe N thenu € Eve.has. 


Proof: Analogous to the proof of Lemma 6.4. qo 
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7.4 Implementation Proof 


We show that Sz implements KD(U, P, K, A) using a simulation relation. The relation F' is 
defined by saying that (s,t) € F provided that: 


1. t.chosen-key = exp(s.DH(p1).chosen-base, s.DH (p2).chosen-exp) if s. DH (p1).chosen-exp # 
| and s.DH(p2).chosen-exrp # L; t.chosen-key = | otherwise. 


2. t.notified = {p € P: s.DH(p).granted}. 


Condition 1 says that the chosen key in KD is obtained by doubly-exponentiating b0 with 
both the chosen exponents in the Diffie-Hellman protocol. If it is not the case that both 
exponents have been chosen, then the chosen key is undefined. 


Theorem 7.3 F is a simulation relation. 


Proof: Start condition: Easy. 
Step condition: Consider (s,7,s’) and ¢t as usual, and consider cases. The most interesting 
cases are: 


1. © = choose-expy. 


If s.DH(q).chosen-erp = L, where q # p then this maps to the trivial one-state 
execution fragment t. The correspondence is trivially preserved (Part 1 is vacuous). 
Otherwise, this corresponds to choose-key, with a chosen value of 

exp(s’.DH (p1).chosen-base, s'. DH (p2).chosen-exp). 

Enabling is straightforward, as is the preservation of the simulation relation. 


2. 7 = grant(b), 
This corresponds to grant(b), in the specification. The interesting fact to show here 
is the enabling condition, in particular, that b = t.chosen-key. The precondition of 7 
in the implementation implies that b = erp(s.DH (p).rcud-base, s.DH (p).chosen-exp). 
But Lemma 7.1 implies that b = exp(s.DH(q).chosen-base, s.DH (p).chosen-exp), 
and properties of the cryptosystem imply that this is equal to 
exp(exp([b0], s.DH (p1).chosen-exp), s.DH (p2).chosen-exp). Then the definition of F 
says that this is equal to t.chosen-key, as needed. 


3. 7 = reveal(u)a 


This corresponds to reveal(u)q in the specification. We must show that u ¢ K. The 
precondition for reveal(u)q (in Eve) implies that u € s.Eve.has. Lemma 7.2 implies 
that u ¢ N, which implies that u ¢ K, as needed. 


Theorem 7.4 S2(C,P, A) implements KD(U, P, K, A). 


Proof: By Theorems 7.3 and 3.1. o 
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8 Algorithms Using Structured-Key Cryptosystems 


In this section, we modify the implementations of private communication and of key dis- 
tribution, S, and So, so that they use a common structured-key cryptosystem, rather than 
separate shared-key and base-exponent cryptosystems. We show that the resulting systems 
are still correct. The proofs use simulation relations to the original systems. 

Throughout this section, and for the rest of the paper, we fix C to be any augmented 
structured-key cryptosystem. 


8.1 Private Communication 


We show that moving from a shared-key cryptosystem to a structured-key cryptosystem 
does not disturb the correctness of the simple shared-key communication protocol. The 
key idea is that the new mechanisms added to the cryptosystem do not contribute any new 
ways of computing messages of the original shared-key cryptosystem. 


8.1.1 Notation and assumptions 


Starting from the fixed augmented structured-key cryptosystem C, we derive a shared-key 
cryptosystem C’, by defining MConste: = MConstc and KConstc: = B2c¢. That is, we use 
the B2 terms in C as “names” for keys in C’. 

In this subsection we assume that P is a set with at least 2 elements, A is a nonempty 
finite set, U = sete, M = [MConstc], K =|B2c], and X = [XConst1¢] U |[XConst2¢]. 

We also define W to be the set of all elements w € setc(“M”) that can be obtained as 
follows. In cryptosystem C, w is obtained from an element m € sete:(“M”) by applying 
some number (possibly 0) of enc operations with second arguments in setc(“B”) — K. 
Informally speaking, w is obtained by “wrapping” some message of the derived shared-key 
cryptosystem in a series of encryptions based on keys not in B2. Finally, we assume that 
N=WUKUX,U' =U = setc, and A’ is a nonempty finite set, disjoint from A. 

The set W is used to describe the elements of type “M” that the eavesdropper is not 
allowed to learn. We have chosen this particular set W because it has a simple definition, 
because it includes all elements of type “M” that could help the eavesdropper to compute 
elements that are supposed to remain unknown (the MConsts), and because it excludes 
values produced by other protocols with which the given protocol is to be composed. Other 
choices of W besides ours are possible. 


8.1.2. New implementation 


The formal definitions of Enc’ and Dec8 are nearly identical to those of Enc and Dec. The 
difference is that the new automata use elements of type “B” in place of KConsts. Also, 
the parameters have new meanings, as defined just above. 


Enc3(C,P)pq where p,qgeP, pq: 


Signature: 
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Input: Output: 
PC-send(m)p,qg, m € [MConstc] IC-send(u) p,q, m € sete 
grant(u)p, u € sete 


States: 


buffer, a multiset of elements of [MConstc], initially empty 
shared-key € setc(“B”) U {L}, initially L 


Transitions: 
PC-send(m)p,q grant(u)p 
Effect: Effect: 
add m to buffer if u € setc(“B”) then 


shared-key := u 
IC-send(u) p,q 
Precondition: 
m is in buffer 
shared-key # L 
u = enc(m, shared-key) 
Effect: 
remove one copy of m from buffer 


Dec(C, P)yq, where p,qeEP,p#q: 


Signature: 
Input: Output: 
IC-receive(u)p,q, u € sete PC-receive(u)p,q, u € sete 


grant(u)g, u € sete 


States: 


buffer, a multiset of elements of setc(“M”) 
shared-key € setc(“B”) U {1}, initially L 


Transitions: 
IC-receive(u) p,q grant(u)q 
Effect: Effect: 
if u € setc(“M”) then if u € setc(“B”) then 
add u to buffer shared-key := u 


PC-receive(u) p,q 
Precondition: 
m is in buffer 
shared-key # L 
u = dec(m, shared-key ) 
Effect: 
remove one copy of m from buffer 


We define 53 to be the system from Section 6, but implemented using the structured- 
key cryptosystem C rather than a shared-key cryptosystem. That is, $3(C,P,A,U’, A’) is 
constructed by composing: 
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e Enc3(C,P)p¢q and Dec3 (C,P)pq,p.9d€ P, pF. 
e IC(U, P, A), Eve(C, P, A), Env(U, A, N). 
© KD(U',P,K, A’). 


and then hiding all the eavesdrop, IC-send, IC-receive, grant, and learn actions, and the 
reveal, actions for a € A’. That is, we hide all actions except the external actions of 
PC(U, P, M, A), which are the PC-send and PC-receive actions and the reveal, actions for 
a € A. We want to show that $3(C, P, A,U’, A’) implements PC(U, P, M, A). 


8.1.3. Invariants 
Lemma 8.1 In all reachable states of S3, the following are true: 


1. For all p, Enc3 py 4.shared-key € K U{L}. 


2. For all p, Dec3yq.shared-key © K U{L}. 


Proof: By induction; the only interesting case is grant, but this is straightforward from the 
precondition of grant in KD. o 
Lemma 8.2 In all reachable states of S3, the following are true: 

1. For all p,q, if u € IC .buffer(p,q) then u = enc(m,k), wherem eM andke K. 


2. For all p,q, alla € X, x ¢ IC .buffer(p, ¢q). 


Proof: Part 1 is proved by induction, using Lemma 8.1. The interesting case is IC-sendp q; 
this follows because the precondition (in Enc3) implies that the message sent is of the 
indicated form. Part 2 follows from Part 1. 0 


Lemma 8.3 In all reachable states of S3, the following are true: 
1. No element of X is in Eve.has. 


Proof: By induction. The interesting cases are: 


1. eavesdrop (u)p,q,a 
Lemma 8.2 implies that u = enc(m,k) for some m € M and k € K. This is not in X, 
which shows that the invariant is preserved. 

2. learn(u)a 
The precondition (in Env) implies that u ¢ X, so this cannot cause a violation of the 
claim. 

3. compute(u, fa 


Since no element of X can be computed in cryptosystem C, the claim is preserved. 
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The following lemma, Lemma 8.4, has a different style from the other invariants we have 
stated so far. It does not say that no element of W may appear in has. Rather, it says 
that if such an element, w, appears in has, then any element m of sete (“M”) that is easily 
reachable from w, for example, the “unwrapped” element of sete:(“M”) from which w is 
constructed, must also be in has. 

Also note that we do not give any invariants here saying that K or M elements do not 
appear in Eve.has, as we did in Section 6.3. This is because (in the spirit of modularity) 
we prefer to avoid re-proving facts for $3 that have already been proved for 5}. 


Lemma 8.4 In all reachable states of S3, the following are true: 


1. Assume that (MU K)N/ Eve.has = 0. If w © WN Eve.has and m € sete: (“M”) is 
easily reachable from {w} U (setce(“B”) — K) inC, thenm © Eve.has. 


Proof: By induction. Fix (s,7,s’) as usual. The interesting cases are: 


1. eavesdrop (u)p,q,a 


Note that the form of u, as described in Lemma 8.2, implies that u © W. The 
interesting situation is where w, the element in the statement of the invariant, is 
equal to u, the element newly inserted into has. So suppose that m € sete: is easily 
reachable from {u} U (sete(“B”) — K) in C. Then properties of the cryptosystems C 
and C’ imply that m = u. But wu is explicitly put into Eve.has by this step, as needed. 


2. learn(u)a 


The precondition (in Env) implies that u ¢ W, so this cannot cause a violation of the 
claim. 


3. compute(u, fa 


The interesting case is where the new element u being computed is in W, so assume 
that u € W. Suppose that (MU K) 1 s'.Eve.has = Q and that m € sete’ is easily 
reachable from {u} U (setc(“B”) — K) in C. It follows that (M UK) s.Eve.has = 0. 


If the function f is exp, then some element of X must be in s.Eve.has. But Lemma 
8.3 implies that there is no such element. So f must be either enc or dec. Since no 
element of K is in s.Eve.has, the second argument in the application of f must be in 
setc(“B”)—K. The first argument is some u’ € s.Eve.has. It follows that m is easily 
reachable from {u’} U (sete(“B”) — K) in C. Also, since u € W, properties of the 
cryptosystem C imply that also u’ € W. But then the inductive hypothesis implies 
that m € s.Eve.has. Therefore, m € s’.Eve.has, as needed. 


8.1.4 Implementation proof 


We prove the correctness of $3 as a consequence of that of $,(C’,P,A,U’, A’). By our 
previous result about S;, Theorem 6.6: 


Lemma 8.5 S)(C', P, A,U’, A’) implements PC (sete, P, M, A). 


25 


In order to prove correctness of S3(C,P,A,U’, A’), we would like to demonstrate a 
simulation relationship from $3(C,P, A,U’, A’) to S,(C’, P, A,U’, A’). To do this, we first 
make the interfaces consistent, by defining 53(C, P, A,U’, A’) from $3 by hiding the actions 
reveal(u)a, u€ U — sete, aE A. 


Lemma 8.6 /f 3 is a trace of S3(C, P, A,U’, A’) then B with all reveal(u) actions removed, 
u €U — sete, is a trace of S5(C’, P, A,U', A’). 


Now we define the relation F from $3(C,P,A,U', A’) to S\(C’, P,A,U', A’): (s,t) € F 
provided: 


1. For all components except Eve, the states are identical in s and t. 


2. s.Eve.has MN sete: C t.Eve.has. 
Theorem 8.7 F is a simulation relation. 


Proof: Start condition: Easy. 
Step condition: Consider (s,7,s’) and ¢ as usual. 

We claim first that no element u € MUK appears in s.Eve.has. For, if such an element 
did appear in s.Eve.has, the fact that (s,¢) € F would imply that u € t.Eve.has. But this 
would contradict Lemma 6.4, an invariant for S$}. 

The most interesting cases are: 


1. r= reveal(u)g, aE A 


We consider two subcases: 


(a) u € sete 
Then the corresponding fragment consists of a single step, with the same action. 
The precondition of 7 in S4 implies that u € s.Eve.has. Since (s,t) € F’, we have 
also that u € t.Eve.has. Therefore, 7 is enabled in t. Since reveal actions have 
no effect on the state, the relation F’ is preserved. 

(b) u €U — sete 
Then the corresponding fragment consists of the single state t. Since a is an 
internal action of $5, the external behavior corresponds as needed. 


2. m = compute(u, f) 


(a) u € sete 
Then since f € ENc, f must be exp, enc, dec, or an element of BConst. We 
consider cases: 


i. f = enc or f = dec, with the second argument in K. 
Then the precondition implies that this K element, say k, must be in 
$.Eve.has. But this contradicts a claim at the beginning of the proof, which 
means that this case cannot occur. 
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ii. f = enc, with the second argument in setc(“B”) — K 
Then properties of the cryptosystem C imply that f yields a result u € 
(U — sete:), contradicting the requirements of this case. 

iii. f = dec, with the second argument in setc(“B”) — K 
Then the corresponding fragment consists of the single state t. We must show 
that the correspondence is preserved. By properties of the cryptosystem C, 
the first argument of f must be some element w € W. By the precondition 
of 7, w € s.Eve.has. Then Lemma 8.4, together with the fact that (MU 
K)s.Eve.has = 0, implies that u € s.Eve.has, that is, u is already in the 
has set, before the current step. Therefore, since (s,t) € F', we have also 
u € t.Eve.has. It follows that (s’,t) € F, that is, the correspondence is 
preserved. 

iv. f = exp 
Then f must be applied with a second argument x € X, and x € s.Eve.has. 
But this violates an invariant for $3, Lemma 8.3, which means that this case 
cannot occur. 

v. f € BConste 
This yields a result u € (U — sete’), contradicting the requirements of this 
case. 


(b) u €U — sete 
Then the corresponding fragment consists of the single state t. Since u ¢ sete, 
the correspondence is preserved. 


3. 7 = learn(u)a 


(a) wu € sete 
Then the corresponding fragment consists of a single step, with the same action. 
To see that this is enabled, note that u ¢ N, by the precondition in $3. In 
particular, u ¢ M UK. This implies that learn(u) is enabled in S;. Since the 
same element is added to both has sets, the correspondence is preserved. 

(b) u EU — sete 
Then the corresponding fragment consists of the single state t. Since u ¢ sete, 
it is easy to see that the correspondence is preserved. 


4. © = eavesdrop (u)p,q,a 


The precondition of 7 in $3 implies that u € s.JC.buffer,,. Since (s,t) € F’, we have 
that also u € t.[C.buffer, ,. Therefore, 7 is enabled in t¢. Since the same element is 
added to both has sets, the correspondence is preserved. 


Theorem 8.8 53(C, P, A,U’, A’) implements 5,(C’, P,A,U', A’). 


Proof: By Theorems 8.7 and 3.1. o 
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Lemma 8.9 /f 3 is a trace of S3(C, P, A,U’, A’) then B with all reveal(u) actions removed, 
for u €U — sete, is a trace of S\(C’, P, A,U', A’). 


Proof: By Theorem 8.8 and Lemma 8.6. oO 


Theorem 8.10 $3(C, P,A,U’, A’) implements PC(U, P, M, A). 


Proof: Let @ be a trace of $3(C, P, A,U’, A’). Then Lemma 8.9 implies that (3) is a trace 
of $\(C’, P, A,U', A’), where (, is equal to @ with all reveal(u) actions removed, for u € 
U — setcr. Then Lemma 8.5 implies that 3, is a trace of PC(sete, P, M, A). It follows that 
GB, is a trace of PC(setc, P,M, A). Now, since @ differs from (, only by including some 
reveal actions for elements in U — sete, it follows that (3 is a trace of PC(setc, P, M, A). 
O 


The proofs of the results in this and the next subsection deal with specific cryptosystems. 
It would be interesting to extract general theorems that could be applied to get such results. 
Such theorems would involve some kind of notion of “embedding” of one cryptosystem in 
another, and statements articulating when a protocol that works with a cryptosystem also 
works with any cryptosystem in which that cryptosystem is embedded. 


8.2. Key Distribution 


It is not hard to see that moving from a base-exponent cryptosystem to a structured-key 
cryptosystem does not disturb the correctness of the Diffie Hellman protocol. The key idea 
is that the new mechanisms added to the cryptosystem involve the new message type “M”, 
and do not contribute any new ways of computing bases or exponents. 

We proceed formally as in the previous subsection. Starting from the fixed augmented 
structured-key cryptosystem C, we derive an augmented base-exponent cryptosystem C’ 
by defining BConstc: = BConstce, XConstle = XConst1e, XConst2e: = XConst2c¢, and 
b0c = b0c. In this subsection we assume that P = {pl,p2}, A is a nonempty finite set, 
U = sete, K =[B2c], X = [XConst1e] U[XConst2c¢], and N= KUX. 

The new endpoint automata are syntactically the same as the old endpoint automata. 
The only difference is that the subscript C now refers to a structured-key cryptosystem. 
We define S, to be the system from Section 7, but implemented using the structured- 
key cryptosystem C rather than a base-exponent cryptosystem. That is, S4(C,P, A) is 
constructed by composing: 


e DH(C,P)y, p € P. 
e IC(U, P, A), Eve(C, P, A), Env(U, A, N). 


and then hiding the eavesdrop, IC-send, IC-receive, and learn actions. That is, we hide 
all actions except the external actions of KD(U, P,K,A), which are the grant and reveal 
actions. We want to show that 54(C,P, A) implements KD(U, P, K, A). We show this as a 
consequence of the correctness of $2(C’, P, A). By our previous result about $2, Theorem 
7.4: 


Lemma 8.11 $(C’, P, A) implements KD(setc, P, K, A). 
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In order to prove correctness of $4(C, P, A), we would like to demonstrate a simulation 
relationship from $4(C, P, A) to S(C’, P, A). We define S/,(C,P,A) from $4 by hiding the 
actions reveal(u)q, u € U — sete, a€ A. 


Lemma 8.12 If G is a trace of S4(C,P, A) then GB with all reveal(u) actions removed, for 
u €U — sete, is a trace of S4(C', P, A). 


Now we define the relation F' from $)(C, P, A) to S2(C’, P, A): (s,t) € F provided: 
1. For all components except Eve, the states are identical in s and t. 


2. s.Eve.has N sete C t.Eve.has. 
Theorem 8.13 F is a simulation relation. 


Proof: Analogous to that of Theorem 8.7. 
Start condition: Easy. 
Step condition: Consider (s,7,s’) and t as usual. The most interesting cases are: 


1. m= reveal(u)a 


Analogous to the reveal case in the proof of Theorem 8.7. 


2. m = compute(u, f) 


(a) u € sete 
Then properties of the structured-key cryptosystem imply that f must be either 
exp or an element of BConst. Moreover, any arguments required by f are also in 
sete’. Since such arguments must be in s.Eve.has (by the enabling condition), 
the definition of F’' implies that they are also in t.Eve.has. It follows that a is 
enabled in tf. 
Thus, we may allow the corresponding fragment to consist of a single step, with 
the same action. Since the same element is added to both has sets, the corre- 
spondence is preserved. 

(b) u EU — sete 
Analogous to the corresponding case for the compute action in the proof of 
Theorem 8.7. 


3. mw = learn(u)a 


(a) u € sete 
Then the corresponding fragment consists of a single step, with the same action. 
To see that this is enabled, note that u ¢ N = K UX, by the precondition in $4. 
This implies that learn(u) is enabled in Sp. Since the same element is added to 
both has sets, the correspondence is preserved. 

(b) u €U — sete 
Then the corresponding fragment consists of the single state t. Since u ¢ sete, 
it is easy to see that the correspondence is preserved. 
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4. © = eavesdrop (u)p,q,a 


Analogous to the eavesdrop case in the proof of Theorem 8.7. 


Theorem 8.14 5S/(C,P, A) implements S9(C’, P, A). 


Proof: By Theorems 8.13 and 3.1. o 


Lemma 8.15 If @ is a trace of S4(C,P, A) then 8 with all reveal(u) actions removed, for 
u €U — sete, is a trace of S2(C’, P, A). 


Proof: By Theorem 8.14 and Lemma 8.12. O 


Theorem 8.16 S4(C, P, A) implements KD(U, P, K, A). 


Proof: Let @ be a trace of S4(C,P, A). Then Lemma 8.15 implies that 6) is a trace of 
S9(C’, P, A), where (; is equal to 6 with all reveal(u) actions removed, for u € U — sete. 
Then Lemma 8.11 implies that (6) is a trace of KD(setc,P,K,A). It follows that (3, is 
a trace of KD(setc, P, K,A). Now, since ( differs from (, only by including some reveal 
actions for elements in U — seter, it follows that @ is a trace of KD(setc, P, K, A). O 


9 Putting the Pieces Together 


Now we describe how to put the previous results together, to get an implementation of 
private communication that uses the shared-key communication protocol in combination 
with the Diffie-Hellman key distribution service. The first step combines the two protocols 
using ordinary composition, but still keeps the insecure channels, eavesdroppers, and envi- 
ronments for the two algorithms separate. The second step combine the two channels into 
one and likewise for the eavesdroppers and the environments. 


9.1 Composing Diffie-Hellman and Shared-Key Communication to get 
Private Communication 


Recall that we have already fixed C to be an augmented structured-key cryptosystem. We 
now assume, for the rest of the paper, that U = sete, P = {pl,p2}, P’ = {pl’,p2'}, A 
is a nonempty finite set, M = [MConstc], K = [B2c], X = [XConst1e] U [XConst2c¢], W 
is the set of elements of setc(“M”) that can be obtained from elements of sete: (“M”) U 
(sete(“B”) — K) inC using enc, N=WUK UX, and A’ is a nonempty finite set, disjoint 
from A. 

The combined system Ss is constructed by composing: 


e Enc3(C,P)pq, Dec3(C,P)p4q, PVE P, DF. 
e DH5,, p © P; each of these is a renamed version of DH(C, P),, with the subscripts in 


IC-sendpq and IC-receiveg» actions renamed to their primed versions. 
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Figure 3: S5 


e IC(U, P, A), Eve(C, P, A), Env(U, A, N). 
e IC(U, P’, A’), Eve(C, P’, A’), Env(U, A’, N’). 


and hiding all actions except for the external actions of PC(U,P,M,A), which are the 
PC-send, PC-receive, and reveal, actions for a € A. Figure 3 contains an interaction 
diagram for S's. 


Theorem 9.1 Ss implements PC(U, P, M, A). 


Proof: This follows from Theorems 8.16 and 8.10, using general projection and pasting 
lemmas for I/O automata. Let a be an execution of S;. We produce an execution a’ of 
PC(U, P, M, A) such that trace(a’) = trace(a). 

Define T, = Enc3 p12 X Dec3 p1,p2 X Enc3y2,p1 X Dec3 p2,91 x IC (U, P, A) x Eve(C, P, A) x 
Env(U, A, N) and Tz = DH5y; x DH5y2 x IC(U, P', A’) x Eve(C, P’, A’) x Env(U, A’, N’). 
Define ay = a|T; and ag = alT). By I/O automaton projection lemmas, a; and ag are 
executions of T; and T2, respectively. (See [23], Chapter 8.) 

Let T3 be the same as T> but with all actions except for the grant actions and reveal 
actions hidden; ag is also an execution of T3. Then 73 is exactly the same as S4(C, P, A’) 
except for renaming of elements of P, everywhere except in grant actions, to corresponding 
elements of P’. By Theorem 8.16, 54(C, P, A’) implements KD(U, P, K, A’). Since all the 
renaming happens internally, this implies that T3 implements KD(U, P, K, A’). 

It follows that there exists an execution a3 of KD(U, P, K, A’) that agrees with a2, and 
so also with a, on the external actions of KD(U, P, K, A’), that is, on the grant(u), actions, 
u€U,p€ P and reveal(u), actions, u€ U,a € A’. 
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Now I/O automaton pasting lemmas (see [23]) yield an execution ay of T; x KD(U, P, K, A’) 
such that a4|T; = a; and a4|KD(U, P, K, A’) = a3. Thus, ay agrees with a on T; and on 
the external actions of KD(U, P, K, A’). 

Now define T; = T, x KD(U, P, K, A’), with all except the PC-send, PC-receive and 
reveal(a), a € A actions hidden. Note that T, = S3(C,P,A,U, A’). Now Theorem 8.10 
implies that $3(C,P,A,U,A') implements PC(U, P, M, A); therefore, there is an execution 
a’ of PC(U, P, M, A) that agrees with ay on all external actions of PC(U, P, M, A). Hence, 
a’ agrees with a on all external actions of PC(U, P, M, A). This is as needed. O 


9.2 Merging Channels, Adversaries, and Environments 


The final implementation, Sg, is obtained from Ss; by merging the two separate insecure 
channels into one, and likewise for the two adversaries and the two environments. To do 
this, and yet keep the same interfaces, we extend the definitions of JC and Eve to allow 
two types of ports, primed and unprimed. S¢ consists of: 


e Laced (C,.P yng) Decd(€. Pia Pt CL ep F @ 
© DH5y,péP. 

© IC(U,P, A, P', A'), Eve(C, P, A, P', A’). 

© Env(U, AUA', NUN’). 


Here, the extended IC is the same as IC(U,P U P’, A U A’) but only has actions with 
subscripts p,q,a where either p,q € P, a € A or p,q € P’, a € A’. Similarly for the 
extended Eve. Also, Sg hides all actions except for the PC-send, PC-receive, and reveal, 
actions for a € A, that is, the external actions of PC'(U, P, M, A). 

The combined eavesdropper eavesdrops and learns on all adversary ports in AU A’, and 
can use all this information in calculating its has information, which resides in a single state 
component. The combined environment avoids communicating any information in N UN’. 
We claim that Sg implements S;, which implies that Sg implements PC(U,P,M, A). To 
prove this result, we define $7, which is just like S except that it combines the eavesdroppers 
(but not the channels or environments). We define a simulation relation F' from $7 to Ss, 
where (s,t) € F exactly if: 


1. For all except the Eve components, the states are identical in s and t. 
2. s.has C t.Eve(C, P, A).has. 
3. s.has C t.Eve(C, P’, A’).has. 


This relation says, essentially, that any information that the combined eavesdropper can 
acquire, in the context of the given protocols, is something that each of the individual 
eavesdroppers could acquire anyway. 


Theorem 9.2 F is a simulation relation. 
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Proof: The initial condition is immediate, because s.has is empty. For the step condi- 
tion, the interesting cases are as follows. Let b and b’ be arbitrary elements of A and J’, 
respectively. 


1. reveal(u)a,aEA 


We know that u € s.has. So by definition of F’, we have that u € t.Eve(C, P, A).has. 
Let this step correspond to a single step, with the same reveal(u)q action. Since 
u € t.Eve(C, P, A).has, this action is enabled in Ss. 


2. reveal(u)a, a € A’ 


Analogous to the previous case. 


3. learn(u)a,a€ AUA’ 


The execution fragment corresponding to this step consists of two steps, with actions 
learn(u)p, learn(u)y. By the precondition, u € U —(NUN’). Sou € (U—N) and 
u € (U —N’'). It follows that the two learn actions are enabled in S5. Since the same 
element u is added to all three has sets, the correspondence is preserved. 


4. compute(u, f)a, aE AU A’ 


The execution fragment corresponding to this step consists of two steps, with ac- 
tions compute(u, f),, compute(u, f)y. The precondition implies that all the arguments 
needed for this computation of f are in s.has. Since (s,t) € F’, these areguments are 
also in t.Eve(C, P, A).has and in t.Eve(C, P’, A’).has. It follows that the two compute 
actions are enabled in $5. Since the same element u is added to all three has sets, the 
correspondence is preserved. 


5. eavesdrop(u)a,aE A 


Then Lemma 8.2 implies that u is of the form enc(m,k), m € M, k © K. There- 
fore, u € U—N’'. The corresponding fragment consists of two steps, with actions 
eavesdrop (u)q, learn(u)y. The eavesdrop action is enabled in Ss; because the chan- 
nel states are identical in states s and t. The learn action is enabled in S7 because 
u€U—N’. Again, since the same element u is added to all three has sets, the 
correspondence is preserved. 


6. eavesdrop(u)a, a € A’ 


Then wu is of the form exp(b0,7) € U—N. The corresponding fragment consists of two 
steps, with actions eavesdrop(u)!,, learn(u)y. The eavesdrop action is enabled in S5 
because the channel states are identical in states s and t. The learn action is enabled 
in S7 because u € U—N. Since the same element u is added to all three has sets, the 
correspondence is preserved. 


Theorem 9.3 S7 implements Ss. 


Proof: By Theorems 9.2 and 3.1. o 
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The essence of Theorems 9.2 and 9.3 is a relationship between Eve(C, P, A, P’, A’) and 
the composition Eve(C, P, A) x Eve(C, P’, A’). The reason that this relationship is described 
in terms of the complete systems $7 and S; (rather than just the eavesdroppers) is that the 
relationship depends on assumptions about the contexts in which the eavesdroppers run. 
The key facts used about the contexts appear in the arguments for the eavesdrop cases in 
the proof of Theorem 9.2. Basically, these facts say that any message that can appear in 
the insecure channel of either protocol could also be generated by the environment in the 
other protocol. It is possible to extract a general combining theorem for eavesdroppers, 
using abstract models of the environments and protocols that express just this type of 
noninterference. Since this involves some notational complexities, we leave this for future 
work. 


Lemma 9.4 S¢ implements S7. 

The fact that Sg implements 57 is easy, based on the following two lemmas: 
Lemma 9.5 Env(U, AU A’, NUN’) implements Enu(U, A, N) x Env(U, A’, N’). 
Lemma 9.6 IC(U, P, A, P', A’) implements IC(U, P, A) x IC(U, P’, A’). 

This all yields: 

Lemma 9.7 Sg implements Ss. 


Proof: By Lemma 9.4 and Theorem 9.3. O 


Theorem 9.8 S¢ implements PC(U, P, M, A). 


Proof: By Lemmas 9.7 and Theorem 9.1. 0 


10 Discussion 


In this paper, we have modeled and analyzed the combination of simple shared-key commu- 
nication with Diffie-Hellman key distribution, in the presence of an eavesdropper adversary. 
Even though this example is very simple, we have studied it using many kinds of decompo- 
sition, including: 


1. Separating distributed algorithms issues from other issues, like cryptosystem reacha- 
bility issues. 


2. Treating the two sub-protocols separately, then combining them using general theo- 
rems about automaton composition. 


3. Giving high level service specifications, giving detailed descriptions of implementing 
algorithms, and using simulation relations to show that the algorithms implement the 
services. 


34 


4. First studying the protocols using simple cryptosystems and later extending them to 
use more elaborate cryptosystems. 


5. Combining separate adversaries into one. 


We believe that understanding these decomposition methods in a simple context is an 
important first step toward extending them to more complicated protocols. 

It appears possible to decompose the presentation in this paper even more. For example, 
one might define a notion of embeddings of cryptosystems and obtain the results of Section 
8 as consequences of general theorems about such embeddings. Or, one might formulate 
and prove a general combining theorem for eavesdroppers and use it in the proof of Lemma 
9.4. 

In work in progress, we are extending these ideas to more complex protocols like that 
of Diffie, van Oorschot, and Weiner [11], which tolerate more active adversaries. So far, it 
appears that the modeling/analysis ideas of this paper scale well to the more complicated 
examples. Some issues that arise in modeling the protocol of [11] are: The cryptosystems 
are more complicated, so more complicated arguments must be made about reachability; 
for example, the analogues of the set W defined in Section 8.1.1 become more complicated. 
Also, because the adversary has more active control of the communication system, it is 
appropriate to combine the adversary and communication system into a single automaton 
model. (The has component of that automaton is now used to decide what may be delivered 
to the client, as well as what may be revealed.) Also, the correctness guarantees are weaker— 
for instance, repeated deliveries of the same message, and deliveries to the wrong recipient, 
are allowed. A more complicated key distribution service specification will also be needed, 
including key requests and granting of multiple keys. 

The work of this paper has not addressed liveness properties. For the simple case of 
this paper, with a passive eavesdropper, liveness claims are certainly possible. They can be 
incorporated easily into the model in the form of time bounds, and proved using the usual 
assertional methods for timing analysis, such as those appearing in [5, 22]. For more active 
adversaries, more sophisticated algorithms can guarantee liveness properties, which could 
also be formulated as time bounds and proved similarly. 

Another interesting research direction is the modular introduction of probabilistic con- 
siderations. A great deal of reasoning about security protocols can be carried out in a 
framework in which it is assumed that certain low probability “bad” events simply do not 
occur. Such events might then be introduced separately, and general theorems used to limit 
their impact on system behavior. Such general theorems remain to be developed. 
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